\chapter{Summary and Conclusions}
\begin{flushright}
``If you wish to make an apple pie from scratch, you must first invent the universe.''
\\Carl Sagan
\end{flushright}
Our thesis was done in three stages first was to investigate how to interface C or C++ with Ada, then to create an Ada interface for OpenCv called OpenCvAda the last stage was a communication protocol for the GIMME stereo camera device.
\\
Types in Ada and C are in almost all of the cases equal and when mapping back or forward nothing except the standard types needs to be used, the only case that causes problems is arrays. But the solutions for C arrays in Ada are straightforward and does not move away from standard Ada coding styles, as long as unbounded arrays in Ada are not used. C pointers in Ada might seem tricky but if truth be told, the only case when Ada access and C style pointers do not reference the same things are when used with arrays. One thing that can not be used in Ada from C are macros which needs to be moved to either a C or Ada function instead. Using the C to Ada guide in this report should allow Ada to interface with any C library or object code with access to headers.
\\
Except for C++ code that only uses C types in the parts that is visible to Ada, this would allow only basic types, pointers and references to be used, the first noticeable problem with C++ the name mangling will still not be solved and requires either the C wrapper or extern ``C'' solutions. The main problem with using C++ code is always in one way or another related to a template class or template function and that they are not added as part of the library or object file until an actual instance is created, this was not solvable in the scoop of this report and possible solutions to investigate is discussed in the future work section.
\\
When designing and implementing OpenCvAda the goal was to make it behave like an Ada library while keeping it as familiar as possible to users of OpenCv. This inadvertently created some weird design choices where access types are used a bit to much and should have been hidden away from the user to make OpenCvAda more intuitive to work with. Another problem is regarding the Cv_Seq and Cv_Void types and the design that they should behave like they do in C instead of making any functions using these generic, the reason for them not be generic was the assessment that it would require the user to create several instances of the same package and that it would break dependencies between packages, this should have been looked at more to make OpenCvAda behave more like an Ada library instead of mimicking a C library. Other problems arise due to OpenCv not working properly including broken functionality (camera and video playback to name a few) or samples not tested on current versions making it impossible to even run them in some cases, this is most likely due to OpenCv trying to keep three language versions running at the same time and release testing that seemed to be skipped or just sloppy. If we disregard the changes that should be looked at that we discussed above OpenCvAda is a working interface to OpenCv in C but lacking support for the new functionality only available in the C++ version. 
\\
Benchmarks was created and executed to test the performance of OpenCvAda compared to OpenCV in C and Python in six different categories: Highgui window creation, large image I/O, algorithms, memory usage, OS comparison and correctness. Also a test was done as a reference where an empty application was executed to make sure no unknown bottlenecks existed in the tested platforms. The results are overall positive in 4-2 advantage in observed performance in favor of OpenCvAda, and according to our data from a performance standpoint Windows 7 is the favored platform, but for a better and more detailed picture more tests needs to be run since it makes very little sense for OpenCvAda to be faster then OpenCv in C. The expected results of the OpenCvAda benchmarks is close to the results measured but more like memory and algorithm test where C edges out Ada with small margin and Python being a clear bit away from the other two in performance, without more detailed, different and more executions in the tests it is not possible to find a reason for the actual results where Ada has a lower average then C. 
\\
The GIMME communication protocol was designed to be expandable and favouring high throughput over error handling and correctness. Some error handling still exists and are mostly designed to allow for simultaneous receiving and sending of several transactions at the same time and to be able to replace missing Ethernet frames on the receiving end with dummy data.
\\
The perceived result is that OpenCvAda is not invalidated in either performance or correctness compared to C and Python, so this should be considered a huge success, but changes could be made to make OpenCvAda more user friendly and to change the package layout to not just match the C/C++ version but to make it more clear where to find the different functions and types and easier to find functions and types. 